Skip to content

🐛 Fix deprecation conditions showing install errors and improve condition semantics - #2296

Merged
openshift-merge-bot[bot] merged 1 commit into
operator-framework:mainfrom
camilamacedo86:fix-issue-conditions
Jan 27, 2026
Merged

openshift-merge-bot[bot] merged 1 commit into
operator-framework:mainfrom
camilamacedo86:fix-issue-conditions

Conversation

@camilamacedo86

@camilamacedo86 camilamacedo86 commented Nov 1, 2025 •

Copy link
Copy Markdown
Contributor

Fixes deprecation conditions showing install errors instead of actual deprecation status.

Problems Fixed

1. Install errors leaked into deprecation conditions

When installation failed, the error appeared in ALL conditions including deprecation ones:

- type: PackageDeprecated
  status: "False"
  reason: Failed
  message: "validating bundle: dependency not supported"  # ❌ Wrong place!

Users couldn't tell if something was actually deprecated.

2. Wrong bundle checked during upgrades

When upgrading v1.0.0 → v1.0.1, deprecation showed v1.0.1's status even when the upgrade failed.

This violates Kubernetes convention: status must show actual state, not desired state.


Changes Made

What we do now

Situation What we show
IS deprecated Condition with status: True
NOT deprecated Condition absent (no clutter!)
Can't check catalog Condition with status: Unknown
No bundle installed BundleDeprecated shows status: Unknown, reason: Absent

Key improvements

  1. Install errors stay separate

    • Errors → Progressing and Installed conditions only
    • Deprecation → catalog data only (never errors)
  2. Use installed bundle (not resolved)

    • Checks what's actually running
    • Follows Kubernetes "status = actual state" convention
  3. Correct reason values

    • Deprecated → when True
    • DeprecationStatusUnknown → when Unknown
    • Absent → when no bundle installed (BundleDeprecated only)

Before/After Comparison

What Changed Main (Before) This PR (After)
Install errors Leak into deprecation conditions ❌ Stay in Progressing/Installed only ✅
Catalog unavailable Shows False (misleading) ❌ Shows Unknown (honest) ✅
Bundle reference Uses resolved bundle ❌ Uses installed bundle ✅
Reason values Always Deprecated ❌ Context-specific ✅

Examples

Example 1: Install Error (Bug #2008)

Before:

- type: Progressing
  status: "True"
  message: "validation failed: dependency not supported"
- type: PackageDeprecated
  status: "False"
  reason: Failed
  message: "validation failed: dependency not supported"  # ❌ Error leaked!

After:

- type: Progressing
  status: "True"
  message: "validation failed: dependency not supported"
# ✅ PackageDeprecated absent (error didn't leak!)

Example 2: Catalog Removed

Before:

- type: BundleDeprecated
  status: "False"              # ❌ Misleading: claims "not deprecated"
  reason: Failed

After:

- type: BundleDeprecated
  status: "Unknown"            # ✅ Honest: we can't check
  reason: DeprecationStatusUnknown
  message: "deprecation status unknown: catalog data unavailable"

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. crd-diff-override lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants